The infrastructure of Session Initiation Protocol (SIP) is defined in IETF RFC 3261 (Rosenberg et al., June 2002). In general, SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include, among other things, Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations are used to create sessions carrying session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
In IETF RFC 3265 (A. Roach, July 2002), there is described a SIP event framework to enable event-based information provisioning to any node in the Internet. Examples of this kind of information are presence, location information, content/service availability, or access-controlled SIP events.
As is discussed in RFC 3265, the general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. A typical flow of messages would be:

An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by RFC 3265 that are required to convey such state information.
The SIP event framework as presented in RFC 3265 is a technique to provide context information in general. For example, SIP presence service provides a particular piece of context information, using a particular SIP event package. The SIP presence information may carry availability information about the user (e.g., the user is online or offline, busy, speaking on the phone), activities he is doing, future events learnt through a calendar application, location information supplied by, e.g., a Global Positioning System (GPS) devices, etc.
Some known subscription solutions for SIP events, such as for SIP presence, watcherinfo, and even call-state information, only allow watchers to subscribe to event state information that is associated with a particular resource, where the particular resource is addressed as a SIP URI (Uniform Resource Identifier). For example, a subscription to a presence event is bound to a so-called presentity, representing the user to which the presence information is associated. Hence, when subscribing to event state information, the subscribers subscribe to event state information of a particular, a priori known resource (addressed through the SIP URI). In other words, the watcher always needs to specify the SIP URI of the presentity (or the interested person) in his subscription message.
According to these known solutions, it is not possible to subscribe to event state information that is derivable from a set of state information associated to different URIs. For example, these known solutions do not enable easily discovering all the friends of the watcher which are currently located nearby.
Lately, one solution to this problem has been presented in a published US patent application number U.S. 2005/0289097 by Dirk Trossen and Dana Pavel, assigned to Nokia Corporation. This solution defines a new event package which is used to implement a complex query in a single subscription dialog. With the aid of this solution, it is possible to enable queries for SIP event state data such as:    “Which persons (resources) are in a meeting, the meeting being in a particular location?”, and    “Which persons (resources) are at work right now, with work location Boston, and are not busy?”
One problem with the solution presented in U.S. 2005/0289097, though, is that it needs the definition of a new event package.